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DETAILED ACTION 
Continued Examination Under 37 CFR 1.114 

1 . A request for continued examination under 37 CFR 1.114, including the fee set 
forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this 
application is eligible for continued examination under 37 CFR 1..1 14, and the fee set 
forth in 37 CFR 1 .17(e) has been timely paid, the finality of the previous Office action 
has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 9 
November 2006 has been entered. 

Status of Claims 

2. Claims 1-26, and 28 are pending in the Application. 
Claims 1, 4, 10, 12, 16, 23, 24 and 28 have been amended. 
Claim 27 remains canceled. 

Claims 1-26, and 28 are rejected. 

Response to Amendment 

3. Applicant's amendments and arguments filed on 9 November 2006 in response 
to the office action mailed on 10 August 2006 have been fully considered, but are moot 
in view of the new ground(s) of rejection. 

Claim Rejections - 35 USC § 103 

The following is a quotation of 35 U.S.C. 103(a) which fomis the basis for all 
obviousness rejections set forth in this Office action: 
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(a) A patent may not be obtained though the invention is not identically disclosed or described as set 
forth in section 102 of this title, if the differences between the subject matter sought to be patented and 
the prior art are such that the subject matter as a whole would have been obvious at the time the 
invention was made to a person having ordinary skill in the art to which said subject matter pertains. 
Patentability shall not be negatived by the manner in which the invention was made. 

4. Claims 1-13, 15-26, and 28 are rejected under 35 U.S.C. 103(a) as being 

unpatentable over Dunham (US Patent 6,269,431 B1). in further view of Manley et al. 

(US PG Publication 2003/0182325 Al), hereinafter Manley. 

As for claim 1, Dunham teaches an apparatus for managing incremental storage, 

the apparatus comprising: 

a policy management module (host - Fig. 1 , element 20) configured to set 
a storage management policy for storage capacity of a virtual volume (secondary 
storage - Fig. 1, element 29), wherein the virtual volume is configured to store storage 
data from an storage operation on a primary volume and the virtual volume comprises a 
storage pool that includes at least one storage volume (col. 19, lines 36-47 - the 
storage pool comprises at least one secondary and virtual volume). 

a storage pool management module (backup agent - Fig. 1 , element 25) 
configured to monitor available storage capacity of the virtual volume and to change the 
storage capacity in response to the storage management policy and the available 
storage capacity (the backup agent responds to a request made by the host for a 
backup routine (i.e. change in storage capacity). The backup agent monitors the 
capacity by checking if any spare storage is available - Fig. 15 flow chart, col. 21, lines 
16-63), wherein changing the storage capacity comprise allocating and de-allocating a 
storage volume to the virtual volume in response to the change to the storage capacity 
(Fig. 15, if a spare volume is available, the next virtual volume will be assigned to it - 
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col. 21, lines 16-63). Note additionally Dunham teaches de-allocating volumes in the 
storage after modification access - col. 6, line 33 through col. 7, line 17; and 

an incremental log (secondary directory - Fig. 1 , element 28) 
corresponding to the virtual volume, the incremental log configured to map a virtual 
address assigned to the incremental storage data to a physical storage address of the 
at least one storage volume of the virtual volume (col. 7, line 18 through col. 8, line 15 
and Fig. 10 - secondary directory is responsible for appending information to a file (i.e. 
log) to track and map information stored in the storage pool). 

Despite these teachings Dunham fails to specifically teach incremental 
snapshots (i.e. storage) as claimed by Applicant, rather he teaches performing a full 
backup. 

Manley however discloses a system and method for asynchronous mirroring of 
snapshots at a destination using a purgatory directory and inode mapping in which 
incremental snapshots are added subsequent to the base snapshot (paragraph 0074, 
all lines). 

It would have been obvious to one of ordinary skill in the art at the time of the 
invention for Dunham to further include Manley's asynchronous mirroring of snapshots 
into his own virtual storage system. By doing so, Dunham have a more efficient 
snapshot mechanism, capable of only storing and transferring data that has been 
modified, rather than performing a full backup as taught by Manley in paragraph 0015, 
all lines. 
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As for claims 12 and 24, Dunham teaches a method (and medium comprising 
code configured) for managing incremental storage, the method (and code) comprising 
(configured to): 

monitoring available storage capacity of the virtual volume and to change the 
storage capacity in response to the storage management policy and the available 
storage capacity (the backup agent responds to a request made by the host for a 
backup routine (i.e. change in storage capacity). The backup agent monitors the 
capacity by checking if any spare storage is available - Fig. 15 flow chart, col. 21 , 
lines 16-63), wherein the virtual volume is configured to store incremental storage 
data from an incremental storage operation on a primary volume and the virtual 
volume comprises a storage pool that includes at least one storage volume (col. 19, 
lines 36-47 - the storage pool comprises at least one secondary and virtual volume), 
allocating and de-allocating a storage volume to the storage pool in 
response to the change to the storage capacity of the virtual volume (Fig. 15, if a 
spare volume is available, the next virtual volume will be assigned to it - col. 21 , 
lines 16-63. Note additionally Dunham teaches de-allocating volumes in the 
storage after modification access - col. 6, line 33 through col. 7, line 17),; and 
mapping an incremental log (secondary directory - Fig. 1 , element 28) 
corresponding to the virtual volume a virtual address, assigned to the incremental 
storage data to a physical storage address of the at least one storage volume of 
the storage pool (col. 7. line 18 through col. 8, line 15 and Fig. 10 - secondary 
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directory is responsible for appending information to a file (i.e. log) to track and 
.map information stored in the storage pool). 

Despite these teachings Dunham fails to specifically teach incremental 
. snapshots (i.e. storage) as claimed by Applicant, rather he teaches performing a full 
backup. 

Manley however discloses a system and method for asynchronous mirroring of 
snapshots at a destination using a purgatory directory and inode mapping in which 
incremental snapshots are added subsequent to the base snapshot (paragraph 0074, 
all lines). 

It would have been obvious to one of ordinary skill in the art at the time of 
the invention for Dunham to further include Manley's asynchronous mirroring of 
snapshots into his own virtual storage system. By doing so, Dunham have a 
more efficient snapshot mechanism, capable of only storing and transferring data 
that has been modified, rather than performing a full backup as taught by Manley 
in paragraph 0015, all lines. 

As for claim 16, Dunham teaches a system for managing incremental storage, 
the system comprising: 

a primary volume (col. 19, lines 36-47 describes at least one primary and 
virtual volume); 

a baseline volume configured to store a baseline backup copy of data on 
the primary volume (Fig. 1 , element 29 - secondary storage); 
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a storage pool (secondary storage - Fig. 1, element 29) configured to store 
incremental storage data from an incremental storage operation on the primary volume 
in response to changes in data stored on the primary volume after storing the baseline 
backup copy on the baseline volume, where the storage pool comprises at least one 
storage volume allocated as a virtual volume (col. 19, Wnes 36-47 - the storage pool 
comprises at least one secondary and virtual volume). Referring to Fig. 15, the host 
instructs the backup agent to allocate storage area volumes during required for the 
backup operation; 

a policy management module (host - Fig. 1, element 20) configured to set 
a storage management policy for storage capacity of a virtual volume (secondary 
storage - Fig. 1 , element 29); 

a storage pool management module (backup agent - Fig. 1 , element 25) 
configured to monitor available storage capacity of the virtual volume and to change the 
storage capacity in response to the storage management policy and the available 
storage capacity (the backup agent responds to a request made by the host for a 
backup routine (i.e. change in storage capacity). The backup agent monitors the 
capacity by checking if any spare storage is available - Fig. 15 flow chart, col. 21, lines 
16-63), wherein changing the storage capacity comprise allocating and de-allocating a 
storage volume to the storage pool in response to the change to the storage capacity 
(Fig. 15, if a spare volume is available, the next virtual volume will be assigned to it - 
col. 21, lines 16-63). Note additionally Dunham teaches de-allocating volumes after 
modification access - col. 6, line 33 through col. 7, line 17; and 
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an incremental log (secondary directory - Fig. 1 , element 28) 
corresponding to the virtual volume, the incremental log configured to map a 
virtual address assigned to the incremental storage data to a physical storage 
address of the at least one storage volume of the virtual volume (col. 7, line 18 
through col. 8, line 15 and Fig. 10 - secondary directory is responsible for 
appending information to a file (i.e. log) to track and map information stored in 
the storage pool). 

. Despite these teachings Dunham fails to specifically teach incremental 
snapshots (i.e. storage) as claimed by Applicant, rather he teaches performing a full 
backup. 

Manley however discloses a system and method for asynchronous mirroring of 
snapshots at a destination using a purgatory directory and inode mapping in which 
incremental snapshots are added subsequent to the base snapshot (paragraph 0074, 
all lines). 

It would have been obvious to one of ordinary skill in the art at the time of the 
invention for Dunham to further include Manley's asynchronous mirroring of snapshots 
into his own virtual storage system. By doing so, Dunham have a more efficient 
snapshot mechanism, capable of only storing and transferring data that has been 
modified, rather than performing a full backup as taught by Manley in paragraph 0015, 
all lines. 

As for claim 23, Dunham teaches an lapparatus for managing incremental 
storage, the apparatus comprising: 
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means for monitoring available storage capacity of the virtual volume and 
to change the storage capacity in response to the storage management policy . 
and the available storage capacity (the backup agent responds to a request 
made by the host for a backup routine (i.e. change in storage capacity). The 
backup agent monitors the capacity by checking if any spare storage is available 
- Fig. 15 flow chart, col. 21, lines 16-63), wherein the virtual volume is configured 
to store incremental storage data from an incremental storage operation on a 
primary volume and the virtual volume comprises a storage pool that includes at 
least one storage volume (col. 19, lines 36-47 - the storage pool comprises at 
least one secondary and virtual volume). 

means for allocating and de-allocating a storage volume to the storage 
pool in response to the change to the storage capacity of the virtual volume (Fig. 
15, if a spare volume is available, the next virtual volume will be assigned to it - 
col. 21, lines 16-63. Note additionally Dunham teaches de-allocating volumes in 
the storage after modification access - col. 6, line 33 through col. 7, line 17) - col. 
19, lines 36-47 - the storage pool comprises at least one secondary and virtual 
volume; and 

means for mapping an incremental log (secondary directory - Fig, 1 , 
element 28) corresponding to the virtual volume a virtual address, assigned to 
the incremental storage data to a physical storage address of the at least one 
storage volume of the storage pool (col. 7, line 18 through col. 8, line 15 and Fig. 
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10 - secondary directory is responsible for appending information to a file (i.e. 

log) to track and map information stored in the storage pool). 

Despite these teachings Dunham fails to specifically teach incremental 
snapshots (i.e. storage) as claimed by Applicant, rather he teaches performing a full 
backup. 

Manley however discloses a system and method for asynchronous mirroring of 
snapshots at a destination using a purgatory directory and inode mapping in which 
incremental snapshots are added subsequent to the base snapshot (paragraph 0074, 
all lines). 

It would have been, obvious to one of ordinary skill in the art at the time of the 
invention for Dunham to further include Manley'.s asynchronous mirroring of snapshots 
into his own virtual storage system. By doing so, Dunham have a more efficient 
snapshot mechanism, capable of only storing and transferring data that has been 
modified, rather than performing a full backup as taught by Manley in paragraph 0015, 
all lines. 

As for claim 28, Dunham teaches a method for deploying a computer readable 
medium for managing incremental storage, the method comprising: 

determining customer requirements for incremental storage (Fig. 1 , 
element 23 - the user (i.e. customer) inputs the backup requirements via the host, 
element 20). This input helps the system to determine the specifics of backup required 
by said user; 
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- deploying a storage management program for managing incremental storage, the 
storage management program comprising (the backup agent's operations are 
deployed via the backup software (Fig. 1 , element 224)) 

monitoring available storage capacity of the virtual volume and to change the 
storage capacity in response to the storage management policy and the available 
storage capacity (the backup agent responds to a request made by the host for a 
backup routine (i.e. change in storage capacity). The backup agent monitors the 
capacity by checking if any spare storage is available - Fig. 1 5 flow chart, col. 21 , 
lines 16-63), wherein the virtual volume is configured to store incremental storage 
data from an incremental storage operation on a primary volume and the virtual 
volume comprises a storage pool that includes at least one storage volume (col. 19, 
lines 36-47 - the storage pool comprises at least one secondary and virtual volume). 

allocating and de-allocating a storage volume to the storage pool in 
response to the change to the storage capacity of the virtual volume (Fig. 
15, if a spare volume is available, the next virtual volume wjll be assigned 
to it - col. 21, lines 16-63. Note additionally Dunham teaches de- 
allocating volumes after modification access - col. 6, line 33 through col. 
.7, line 17) - col. 19, lines 36-47 - the storage pool comprises at least one 
secondary and virtual volume; and 

mapping an incremental log (secondary directory - Fig. 1, element 
28) corresponding to the virtual volume a virtual address, assigned to the 
incremental storage data to a physical storage address of the at least one 
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storage volume of the storage pool (col. 7, line 18 through col. 8, line 15 
and Fig. 10 - secondary directory is responsible for appending information 
to a file (i.e. log) to track and map information stored in the storage pool), 
and; 

maintaining the storage management program (col. 15, lines 32-54 - the 
backup program can be reprogrammed and loaded via a floppy disk). 

Despite these teachings Dunham fails to specifically teach incremental 
snapshots (i.e. storage) as claimed by Applicant, rather he teaches performing a full 
backup. 

Manley however discloses a system and method for asynchronous mirroring of 
snapshots at a destination using a purgatory directory and inode mapping in which 
incremental snapshots are added subsequent to the base snapshot (paragraph 0074, 
all lines). 

It would have been obvious to one of ordinary skill in the art at the time of the 
invention for Dunham to further include Manley's asynchronous mirroring of snapshots 
into his own virtual storage system. By doing so, Dunham have a more efficient 
snapshot mechanism, capable of only storing and transferring data that has been 
modified, rather than performing a full backup as taught by Manley in paragraph 0015, 
all lines. 

As for claim 2, Dunham teaches the physical storage address as comprising a 
volume identifier (col, 6, lines 33-63, the pointer points to each physical unit (i.e. the 
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directory intrinsically stores information to identify the address of the data stored in the 
memory, with the corresponding physical volume)). 

As for claim 3, Dunham teaches the storage pool management module as being 
further configured to allocated and de-allocate a portion of a storage volume to the 
storage pool (Fig. 15, if a spare volume Is available, the next virtual volume will be 
assigned to it - col. 21, lines 16*63. Note additionally Dunham teaches de-allocating 
volumes after modification access - col. 6, line 33 through col. 7, line 17), wherein the 
storage pool comprises at least one storage volume allocated as a virtual volume (col. 
19, lines 36-47 - the storage pool comprises at least one secondary and virtual 
volume). 

As for claims 4, 15 and 26, Dunham teaches the apparatus (method and 
medium) as further comprising a read module configured to read data stored in the 
virtual volume by way of a data path independent from a data path used to store the 
storage data (Fig. 2, each host (31, 32, 33) can read data from each storage system via 
a plurality of paths (i.e. through the ring network (30)). More specifically, each host can 
communicate either with the secondary storage device either directly, or indirectly via 
either of the two data storage subsystems) 

As for claim 5, Dunham teaches the storage management module as allocating 
and de-allocating storage volumes without user input (once the backup policy is set, the 
host communicates with the backup agent irrespective of the user input in order to 
effectively manage and backup the volumes (Fig. 15)). 
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As for claim 6, Dunham teaches the storage pool management module as being 
further configured to allocate a second storage volume to the virtual volume in response 
to a reduction in available space on a first storage volume (Fig. 15, more volumes will 
be allocated to create sufficient memory to store the copied data), 

As for claims 7 and 8, Dunham teaches the storage pool as comprising a RAID 
storage array (col. 9, lines 34-53). 

As for claim 9, Dunham teaches the incremental log as comprising a lookup table 
(the directory is used by the system to look up the correspondence between physical 
and virtual addresses - col. 7, line 18 through col. 8, line 15). 

As for claim 10, Dunham teaches the storage pool management module as 
further configured to increase the storage capacity in response to the available storage 
capacity increasing above a first storage capacity threshold and to decrease the storage 
capacity in response to the available storage capacity decreasing below a second 
storage capacity threshold (Fig. 15, the iailocation and de-allocation is dynamically 
determined based on available storage capacity). 

As for claim 1 1 , Dunham teaches the storage pool management module as being 
further configured to de-allocate storage volumes wherein the de-allocated storage 
volumes are available for allocation to a virtual volume unrelated to the storage pool 
(referring to Fig. 2, the plurality of data storage subsystems allows for the de-allocation 
of memory within one of the subsystems. The de-allocated data may at a later time be 
reallocated, just not to a storage area within the other subsystems storage pools). 
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As for claims 13 and 25, Dunham teaches providing incremental snapshot data 
of the primary volume in response to a replication operation (col. 5, lines 57 through col. 
6, line 6 - the snapshot operation is performed in response to the backup operation). 

As for claim 17, Dunham teaches a replication module configured to transmit the 
incremental data from the primary volume to the storage pool (Fig. 3, element 56 - the 
remote link adapter is used to transmit data from the primary storage subsystem to the 
secondary (i.e. storage pool)). 

As for claim 19, Dunham teaches: 

the primary volume comprising a plurality of primary volumes (Fig. 3, 
elements 59-62); . 

the storage pool comprising a storage pool corresponding to each volume (the 
secondary storage area stores backup data of the primary volume in ord.er to maintain a 
copy of the data that corresponds to the data stored in the primary volumes); 

the incremental log comprising an incremental log corresponding to each storage 
pool (col. 7, line 18 through col. 8, line 15); and 

the storage pool management module monitors available capacity of each 
storage pool and allocates and de-allocates storage volumes for each storage pool (the 
backup agent responds to a request made by the host for a backup routine (i.e. change 
in storage capacity). The backup agent monitors the capacity by checking if any spare 
storage is available - Fig. 15 flow chart, col. 21 , lines 16-63), wherein the storage pool 
is configured to store incremental storage data from an incremental storage operation 
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on a volume (col. 19, lines 36-47 - the storage pool comprises at least one secondary 
and virtual volume). 

As for claim 20, Dunham teaches the storage module as being further configured 
to allocated and de-allocate .a portion of a storage volume to the storage pool (Fig. 15, if 
a spare volume is available, the next virtual volume will be assigned to it - col. 21 , lines 
16-63. Note additionally Dunham teaches de-allocating volumes after modification 
access col. 6, line 33 through col. 7, line 17). 

As for claim 21 , Dunham teaches the baseline volume as being part of the 
storage pool (the baseline volume is contained within the secondary volume (Fig. 1, 
element 29)). 

As for claim 22, Dunham teaches the policy management module as residing in a 
host (as per the rejection of claim 1 , supra). 

As for claim 18, Dunham teaches the incremental data comprising snapshot data 
of the primary volume (col. 5, lines 57 through col. 6, line 6 - the snapshot operation is 
performed in response to the backup operation). 

Despite these teachings Dunham fails to specifically teach incremental 
snapshots (i.e. storage) as claimed by Applicant, rather he teaches performing a full 
backup. 

Manley however discloses a system and method for asynchronous mirroring of 
snapshots at a destination using a purgatory directory and inode mapping in which 
incremental snapshots are added subsequent to the base snapshot (paragraph 0074, 
all lines). 
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It would have been obvious to one of ordinary skill in the art at the time of the 
invention for Dunham to further include Manley's asynchronous mirroring of snapshots 
into his own virtual storage system. By doing so, Dunham have a more efficient 
snapshot mechanism, capable of only storing and transferring data that has been 
modified, rather than performing a full backup as taught by Manley in paragraph 0015. 
all lines. 

5. Claim 14 is rejected under 35 U.S.C. 103(a) as being unpatentable over Dunham 
(US Patent 6,269,431 B1) and Manley (US PG Publication 2003/0182325 A1) as 
applied to claim 1 2 above, and in further view of Anaso et al. (US. PG Publication 
2003/0191909 A1), hereinafter Anaso. 

As for claim 14, though Dunham in view of Manley teach all of the limitations of 
claim 12, they fail to teach changing a storage capacity of the storage pool as further 
comprising alerting a user of a storage over-italicization or under-utilization ad changing 
the storage capacity in response to user input. 

Anaso however teaches a storage utilization monitoring system in which the 
system maintains a storage capacity table, which is used to notify the user in case of 
over or under utilization of storage capacity (paragraph 0047,. all lines). 

It would have been obvious to one of ordinary skill in the art at the time of the 
invention for Dunham and Manley to further include Anaso's storage utilization 
monitoring system into his own system of virtual storage devices for recovery of backup 
data. By doing so, Dunham would benefit by having a means more efficiently 
monitoring storage capacity by eliminating the need for a computer itself to perform the 

r 
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monitoring process. This in turn would help Dunham's system to realize could help 
reduce system management costs incurred by system monitoring, as taught by Anaso 
(paragraph 0014, all lines). 

Response to Arguments 

The following arguments presented Applicant have been fully considered but are 
moot in view of the new grounds of rejection: 

6. Under the heading "Rejection of claims 1-13, 15-26, and 28 under 35 U.S.C. 
§1 02(b)", Applicant asserts ''Dunham does not teach, disclose or suggest an 
incremental storage operation, but instead teaches backups and snapshot copies of an 
entire volume" (paragraph 0007). Applicant additional states "Dunham teaches 
checking for spare capacity on the primary volume only as part of a backup recovery 
operation ... not as part of an incremental storage operation" (paragraph 0010). 
Applicant additionally states in paragraph 0012 that Dunham's cited incremental log is 
for snapshotted data and not for incremental storage data as recited by Applicant in this, 
claim. In paragraph 0015, Applicant further contrasts instant claim 1 with Dunham by 
stating "the storage pool management module [of the instant application] allocates and 
de-allocates storage for an incremental storage operation, not the full backup and 
restore operations taught by Dunham". These arguments are rendered moot in view of 
the new grounds of rejection presented supra. 

The following arguments presented by Applicant have been fully considered but 
they are not persuasive: 
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7. Under the heading "Rejection of claims 1-13, 15-26, and 28 under 35 U.S.C. 
§1 02(b)". Applicant asserts "Dunham teaches locating spare storage that is part of the 
primary volume, ... not changing storage capacity of a virtual volume that is mapped to 
a storage pool" (paragraph 0010), and further states "the actions of storage pool 
management module to change the storage capacity of the storage volume correspond 
to locating spare capacity in the primary volume. Applicant contends that this is 
inconsistent with Dunham's storage pool as corresponding to the secondary volume 
(Fig. 1, element.29) as asserted by Examiner. This argument however is not 
persuasive, as Examiner has clarified the rejections of these claims by explicitly stating 
that the management module is responsible for changing the capacity of the pool (which 
corresponds to the secondary storage in Dunham) when the snapshot occurs (i.e. by 
adding the snapshotted data to the secondary storage subsystem). Applicant 
additionally states in this paragraph "monitoring and changing the storage capacity of 
the storage pool is not equivalent to the actions of the backup agent 25, Figure 1 of 
Dunham in responding to a host for a backup routine. Again, locating storage capacity 
on the primary volume is in response to a restoration routine, not a backup routine". 
This argument is not persuasive, as Examiner maintains that the claim requires 
monitoring and changing the capacity in response to a change in storage capacity. 
Dunham teaches this limitation once the host detennines a snapshot is needed, hence 
requiring a change in capacity for both the primary and secondary volumes. 

8. In paragraph 001 1 , Applicant asserts that the cited text (col. 6, line 33 to col. 7, 
line 17) has nothing to do with the recovery process and has nothing to do with de- 
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allocating storage volumes of a storage pool. This argument is not persuasive as 
Examiner maintains the claim requires de-allocating in response to a change in storage 
capacity. Dunham teaches this limitation in col. 6, line 50 through col. 7, line 17 
(volumes are de-allocated from the primary storage and stored in the secondary storage 
as a snapshot in order to free memory within the primary storage area). 

9. In paragraph 0014, Applicant asserts that Dunham fails to teach, "the storage 
management module as being further configured to allocate and de-allocate a portion of 
a storage volume to the storage pool". This argument however is not persuasive as 
Examiner maintains that the secondary storage (i.e. pool) is configured to store data 
from the primary volumes (i.e. data is added to and removed from the secondary 
storage based on data included in a snapshot of the primary volume. 

10. In paragraph 0015, Applicant concedes that some functions of the backup 
process are automated, however alleges that Dunham teaches the occurrence of 
backup in response to a user or to an application, hence fails to teach backing up 
without user input. This argument however is not persuasive. Assuming arguendo that 
Applicant is correct that the cited reference lines (col. 11, lines 25 through col. 12, line 
23) do in fact teach backing the data up in response to user input, Dunham additionally 
teaches the host itself as initiating the backup process in these cited lines, hence 
Examiner has met his burden establishing a prima facia case of obviousness (Dunham 
in view of Manley) for this claim. 

11. In paragraph 0016, Applicant asserts that Dunham's "storage is allocated for 
storing a backup only if the spare capacity is above the amount required to store a copy 
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of the backup". This argument however is not persuasive as Examiner maintains that 
volumes are in fact allocated during the snapshot In order to backup the data 
irrespective of the available capacity (i.e. memory must inherently be "allocated" for data 
for the data to be written to it). 

12. In paragraphs 0017-0018, Applicant asserts that Dunham's fails to teach a first 
and second threshold to determine allocation and de-allocation respectively (i.e. 
Dunham does not teach specific threshold). This argument however is not persuasive 
as Examiner maintains that volumes are allocated and de-allocated based on capacity, 
therefore allocation occurs based on a first threshold (when the system determines that 
data must be stored), and a second threshold (i.e. more data storage area needed)). 
The fact that these thresholds are not statically set or detennined bears no relevance on 
whether or not some sort of threshold must be met in order to either allocate or de- 
allocate memory location within the pool. 

13. Under the heading "Rejection of claim 14 under 35 U.S.C. §1 03(a)", Applicant 
asserts that claim 14 is allowable for at least depending from an allegedly allowable 
claim (i.e. claim 12). This argument is not persuasive, as Examiner maintains that claim 
12 remains rejected under 35 USC § 103(a) per the arguments and rejections 
discussed supra. 
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Conclusion 



14. Any inquiry concerning this communication or earlier communications from the 
examiner should be directed to Craig E. Walter whose telephone number is (571) 272- 
8154. The examiner can normally be reached on 8:30a - 5:00p M-F. 

1 5. If attempts to reach the examiner by telephone are unsuccessful, the examiner's 
supervisor, Hyung S. Sough can be reached on (571) 272-6799. The fax phone 
number for the organization where this application or proceeding Is assigned is 571- 
273-8300. 

16. Infomiation regarding the status of an application may be obtained from the 
Patent Application Information Retrieval (PAIR) system. Status information for 
published applications may be obtained from either Private PAIR or Public PAIR. 
Status information for unpublished applications is available through Private PAIR only. 
For more infomiation about the PAIR system, see http://pair-direct.uspto.gov. Should 
you have questions on access to the Private PAIR system, contact the Electronic 
Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a 
USPTO Customer Service Representative or access to the automated information 
system, call 800-786-9199 (IN USA OR CANADA) or 571-272-ipO^ 
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